For cost-efficiency reasons telecommunication operators are increasingly deploying non-STM (non-Synchronous Transfer Mode) transport technologies inside their networks. Examples of these technologies are ATM (Asynchronous Transfer Mode), IP (Internet Protocol), and FR (Frame Relay). Therefore, a standardised solution is required to support existing services of today's public telecommunication networks over multi-vendor non-STM infrastructures. In the current public telecommunication networks, the call control (CC) and bearer control (BC) are tightly coupled in the same public network protocol, for example, ISUP (ISDN User Part). As a result of this trend to run over multi-vendor non-STM infrastructures, a new network architecture has been developed that allows for the splitting or separating of call control (CC) and bearer control (BC) into separate protocols. FIGS. 1a and 1b show the evolution from current integrated CC/BC public network protocols such as ISUP, to the separated CC/BC solution.
The split of CC and BC functions results in a new interface exposed between the CC function and BC function. A protocol is required to enable the coupling between the CC and BC functions when a telecommunications node is implemented in a separated environment. As an example, the International Telecommunications Union-Telecommunications Sector (ITU-T) and the Internet Engineering Task Force (IETF) have defined a Gateway Control Protocol to enable the coupling between the CC and BC functions. This protocol is designed to control multimedia connections from a remote control entity and operatively resides between the CC functionality and the BC functionality, as shown in FIGS. 1a and 1b. Variants of this protocol are known as H.248 and Q.1950 in the ITU, and Megaco in the IETF.
As a result of the separation of Call Control and Bearer Control, a number of functions which existed in the integrated CC/BC environment require the functionality to be duplicated in the Call Control and the Bearer Control environment. One such function is the “Priority Call” function, which is used, for example, in emergency call situations. The definition of the “Priority Call” function may be found in ITU-T Recommendation I.255.4, Priority Service. In such emergency situations, it is absolutely necessary for emergency calls to progress, but it is not necessary that normal calls progress. Typically, this could be achieved in, for example, one of two ways.
Firstly, if a node receives an emergency call and it has reached its limit of call throughput, the way to allow this emergency call to progress would be to sacrifice, that is terminate, an existing normal call to free up the resources required for the emergency call. Secondly, a node may reserve a certain percentage, for example 2%, of its resources for use by emergency calls only. This means that normal calls cannot use those particular resources. The consequence of this is that in non-emergency situations, the node is running at a sub-optimal capacity. In the example given in this case, 98%. In both of the above examples, it is necessary for the emergency call to be marked as a priority call so that the node can identify the emergency call as such. In the separated CC/BC architecture discussed above, this applies to both call and bearer control protocols, as illustrated in FIG. 2.
In the network configuration of FIG. 2, the call and bearer connections are initiated at Node 1 and terminated at Node 5. The call control traverses the network via Node 3 or path C1-C2 as shown, whereas the bearer control traverses the network via Nodes 2 and 4 or path B1-B2-B3 as shown. To illustrate the emergency call scenario, it is assumed that all nodes and paths are running at or near to full capacity for emergency calls, and a certain percentage of resources on all nodes and paths are reserved for emergency calls. In this particular example, Node 1 initiates an emergency call, and, since it is running at full capacity, it may not use the normal call set up paths. Hence, it selects a path for both the Call Control and Bearer Control, which is reserved for emergency calls, that is, path C1 and path B1, respectively. Similarly, Node 3 should recognise the call as an emergency call and select its internal resources and outgoing path to Node 5 or path C2, appropriately. Likewise, Node 2 should recognise the fact that the bearer path being requested is related to an emergency call, and thus should select its internal resources and outgoing path to Node 4 or path B2, appropriately.
In a separated CC and BC architecture, only the Call Control protocol has an indication that the call has a certain priority. One method of transporting this priority information in the protocol is by the BICC (Bearer Independent Call Control) Precedence indication.
BICC is based on ISUP (Integrated Services Digital Network User Part. That is, the control part of the Signalling System No. 7 protocol, SS7), which is a combined CC/BC protocol. MLPP (Multi-Level Precedence and Preemption Service) is a function in BICC/ISUP. A detailed description of the MLPP is found at ITU-T Recommendation I.255.3 Multi-level Precedence and Preemption Service (MLPP), and ITU-T Recommendation Q.1902.3, Bearer independent call control protocol (CS2) and Signalling System No. 7—ISDN user part formats and codes.
There are currently five Precedence values defined in the BICC protocol, namely flash-override, flash, immediate, priority and routine, which are assigned values 0 to 4 respectively. The Call Control protocol provides for an indication of call priority. Currently the only way Node 2, or Node 4, is aware that the requested bearer set-up is related to an emergency call is that the request is entered on path B1 (or B2). This requires path reservation at a call set up. It thus requires prior network configuration knowledge in Node 2, and also Node 4, which is not always possible or practical in modern switching and non-switching networks, and may require complicated Operation and Maintenance procedures
It is an object of the present invention to overcome or ameliorate at least one of the problems of the prior art.